Knowledge Base Modeller
Posted on 25 Jul 2020; 07:00 PM IST. Last Updated 07 Sep 2020; 05:50 PM IST.Summary: Object Oriented Programming commonly referred to as OOPS, is the de facto programming paradigm, in the software industry. Oops is procedural in nature, and a developer is required to express how a problem needs to be solved, rather than what problem is being solved. Thus, oops tends to be a 3.5GL, rather than a 4GL. Knowledge base Modeller (KBM), is a system comprising of a 4GL, which was proposed to enhance the functionality of oops. KBM is declarative in nature, and allows developers to express the problem being solved, rather than how it is being solved. KBM can be employed for implementing operational models or for modelling knowledge bases, using the declarative 4GL. The KBM 4GL can be easily converted to any 3GL language, and is agnostic to programming language and operating system platforms.
Background
Transaction oriented business systems are often implemented using a 3-Tierd architecture, where the 3 tiers may be described as follows.
a) data objects, derived from the underlying data schema
b) business objects, comprising of business rules based on data objects
c) business services, derived from business objects.
The data object layer is more or less based on SQL databases, and is derived using persistence tools.
The business object layer depicts business rules as methods, which are packaged as business objects.
The business service layer caters to high level user requests or transactions. Typically a business service object makes use of business rules packaged in business objects, to achieve the business objective.
The most typical problems encountered in developing and maintaining large business systems are described below.
Problem-1: Granularity of Business Objects
A business service may use only a few business rules i.e methods of a business object. Thus, if we have too many rules i.e methods in a business object, it may be carrying more dead weight, i.e unused code from the perspective of the current business service.
If we have too few business rules, then we need to instantiate more business objects, to get the work done. The cost of instantiation is always significant, compared to the activity performed by an online transaction.
Thus, it may appear, an ideal packaging scheme would only pick and pack the required business rules into the business service object. But this causes a collapse of the business object layer, and defeats the reusability principle of Object Oriented Systems (oops).
Problem-2: Development and Maintenance of Business Objects
The development of business objects is a simple and a fairly enjoyable exercise, but maintaining these objects is a pretty difficult endeavour. The chief complaint with respect to maintenance is not with respect to coding, but understanding, the effects of the new changes on the system.
Large business systems, typically have thousands of business rules, and many thousands of services. As time passes, the nature of the code or “what it does” is forgotten, and unless a very stringent documentation is maintained, it is pretty difficult to make changes to the codebase. It may be recalled that in 3GL and 3.5GL languages, coding comprises of expressing how a problem is solved, rather than what problem is being solved.
A 4GL would have explicitly expressed “what is being solved”, rather than how it is being solved, and therefore would be more beneficial than a 3GL or 3.5GL.
Problem-3: Development and Maintenance of Service Objects
The development and maintenance of service objects is often a strenuous exercise. A typical problem is understanding how a business object can be instantiated, and the inter dependencies between the various business objects.
An unspecified problem noted in the development and maintenance of service objects is that knitting the business rules i.e methods of the business object, is a rule unto itself. This problem is often poorly understood, recorded or documented.
A rapid application development (RAD) tool, which could automatically develop the code from specification, would greatly alleviate the problems encountered in developing and maintaining service objects.
Proposed System
A system called Knowledge based Modeller (KBM), comprising of a 4GL, was proposed to enhance the functionality of oops. KBM is declarative in nature, and allows developers to express “the problem being solved”, rather than how it is being solved. KBM offers a true 4GL language, and generates code (3 GL or 3.5GL) from the high level 4GL constructs.
Broadly, KBM provides a generic mechanism to represent requirement specifications as concepts. These concepts, which are regarded as colors, can be attached to entity types, to define intended behaviour of an object. The KBM color scheme is of pivotal importance, and provides a facility to describe business rules as KBM rules, in terms of entity types and colors.
Business objects comprising of business rules can be automatically generated by the KBM translator from KBM rules. It may be noted that in this scheme, all business rules included in a business object, are used by the service object.
Service objects can be automatically generated from KBM rules, which can be progressively composed into higher level structures called rule graphs, tasks, activities and workflows.
Thus, KBM helps immensely in the development and maintenance of business systems.
KBM is not restricted to business computing systems and play a significant role in NLP, and in conceptualizing biological, chemical, and mechanical systems.
Description of the System
A detailed description of the KBM system is provided below.
Conclusion
The major benefits of KBM are recited below.
a) 4 GL implies less coding, in an intuitive manner, and the actual java or c# code is generated by the KBM translator.
b) Easy navigation of process flows.
c) If the operations of an application can be recited formally as KBM rules, then these could be automatically converted to a modern language like java or c#. This greatly helps in addressing tough problems like multiple platforms, and migration of legacy applications.